home *** CD-ROM | disk | FTP | other *** search
/ QRZ! Ham Radio 3 / QRZ Ham Radio Callsign Database - Volume 3.iso / digests / tcp / 940026.txt < prev    next >
Internet Message Format  |  1994-06-04  |  16KB
  1. Date: Sat, 29 Jan 94 04:30:06 PST
  2. From: Advanced Amateur Radio Networking Group <tcp-group@ucsd.edu>
  3. Errors-To: TCP-Group-Errors@UCSD.Edu
  4. Reply-To: TCP-Group@UCSD.Edu
  5. Precedence: Bulk
  6. Subject: TCP-Group Digest V94 #26
  7. To: tcp-group-digest
  8.  
  9.  
  10. TCP-Group Digest            Sat, 29 Jan 94       Volume 94 : Issue   26
  11.  
  12. Today's Topics:
  13.                             Circuit Cellar
  14.                                  help
  15.                        Linux & Radio  (2 msgs)
  16.                       Linux: another question...
  17.                          RE - mtu,mss,window
  18.                      TCP MSS and TCP WIN settings
  19.  
  20. Send Replies or notes for publication to: <TCP-Group@UCSD.Edu>.
  21. Subscription requests to <TCP-Group-REQUEST@UCSD.Edu>.
  22. Problems you can't solve otherwise to brian@ucsd.edu.
  23.  
  24. Archives of past issues of the TCP-Group Digest are available
  25. (by FTP only) from UCSD.Edu in directory "mailarchives".
  26.  
  27. We trust that readers are intelligent enough to realize that all text
  28. herein consists of personal comments and does not represent the official
  29. policies or positions of any party.  Your mileage may vary.  So there.
  30. ----------------------------------------------------------------------
  31.  
  32. Date: 28 Jan 94 11:29:34 EST (Fri)
  33. From: Terry Bell <tbell@n8hsp.nshore.org>
  34. Subject: Circuit Cellar
  35. To: TCP-Group@ucsd.edu
  36.  
  37. Send email to 'info@circellar.com'  for info on how to request files via email.
  38. -- 
  39. Terry Bell  N8HSP
  40. tbell@n8hsp.nshore.org  n8hsp@n8hsp.ampr.org  44.70.4.10
  41.  
  42. ------------------------------
  43.  
  44. Date: Sat, 29 Jan 1994 02:10:14 EST
  45. From: "Eric Todd Budinger" <budinger@titan.ds.gen.nj.us>
  46. Subject: help
  47. To: tcp-group@ucsd.edu
  48.  
  49. -- 
  50.  
  51. Eric T. Budinger           Dan's Domain 201-586-1223
  52. budinger@ds.gen.nj.us           Ham Central SysOp
  53. ericbud@ritz.mordor.com         1-201-398-4619 (voice)
  54. n2koj@w2xo.pa.usa.na            1-201-205-2134 (digital)
  55.  
  56. ------------------------------
  57.  
  58. Date: Fri, 28 Jan 94 15:28:07 GMT
  59. From: Alan Cox <iiitac@pyramid.swansea.ac.uk>
  60. Subject: Linux & Radio
  61. To: tcp-group@ucsd.edu
  62.  
  63. Slackware is probably the best choice - nobody uses the latest gcc much yet
  64. because the libraries and tools dont match and the C++ part of gcc 2.5.x is
  65. a real problem at the moment.
  66.  
  67. For radio info and Linux 
  68.  
  69.  mail linux-activists-request@niksula.hut.fi
  70.  X-Mn-Admin: join HAMS  
  71.  (or it might be HAM)
  72.  
  73. Hardly anyone uses it
  74.  
  75. ------------------------------
  76.  
  77. Date: Fri, 28 Jan 1994 17:24:28 -0500
  78. From: "Brandon S. Allbery" <bsa@kf8nh.wariat.org>
  79. Subject: Linux & Radio 
  80. To: tcp-group@ucsd.edu
  81.  
  82. In your message of Fri, 28 Jan 1994 15:28:07 GMT, you write:
  83. +---------------
  84. | For radio info and Linux 
  85. | 
  86. |  mail linux-activists-request@niksula.hut.fi
  87. |  X-Mn-Admin: join HAMS  
  88. |  (or it might be HAM)
  89. | 
  90. | Hardly anyone uses it
  91. +------------->8
  92.  
  93. Lots of us *read* it; however, it seems that the tcp-group, nos-bbs, and 
  94. ka9q-unix mailing lists are used in preference to the Linux-Activists HAMS 
  95. channel.  (This may be because Mail-Net is so klunky.  Someday someone will get 
  96. smart and replace it with listserv...)  There was a brief flurry of activity a 
  97. few months ago that revealed a large number of readers.
  98.  
  99. ++Brandon
  100. --
  101. Brandon S. Allbery    kf8nh@kf8nh.ampr.org   bsa@kf8nh.wariat.org
  102. "MSDOS didn't get as bad as it is overnight -- it took over ten years
  103. of careful development."  ---dmeggins@aix1.uottawa.ca
  104.  
  105. ------------------------------
  106.  
  107. Date: Fri, 28 Jan 94 14:08:22 MET
  108. From: Pierpaolo Pernici <iw5dhe@IW5DHE.AMPR.ORG>
  109. Subject: Linux: another question...
  110. To: tcp-group@ucsd.edu
  111.  
  112. Hello fm IW5DHE, Pierpaolo...
  113. Could someone tell me the best-choice between the linux-distributions !?
  114. I thought that Slackware was the best-choice but I've seen that in the
  115. dist-files there isn't the latest version of GCC... ;^)
  116. Is there a mailing-list for Amateurs_with_Linux !? (rgr Wampes, JNOS,
  117. Ping-Pong conversd, etc... etc..) 
  118. Shold I install JNOS or Wampes !? 
  119.  
  120. Excuse me for all my questions...
  121. All the best,
  122.  
  123. Pierpaolo
  124.  
  125. --
  126. ----------                                                     ----------
  127. Pierpaolo Pernici (IW5DHE)                     == Radio-GW Team - Pisa ==
  128. Surface Address:                               Internet: iw5dhe@amsat.org
  129. Post Office Box nr.8                   AmprNet: iw5dhe@gw.iw5dam.ampr.org
  130. I-56030 S.Pietro Belvedere (PI) Italy  AX25-NET: iw5dhe@iw5cmm.#pi.ita.eu
  131. ----------                                                     ----------
  132.  
  133. ------------------------------
  134.  
  135. Date: Fri, 28 Jan 94 12:14:46 EST
  136. From: crompton@NADC.NADC.NAVY.MIL (D. Crompton)
  137. Subject: RE - mtu,mss,window
  138. To: tcp-group@ucsd.edu
  139.  
  140. Terry,
  141.  
  142.  I am sending this to tcpgroup - your return addresses ans cc's to
  143. were a mile long.
  144.  
  145. The NOS (JNOS) manual has a section towards the rear that describes in
  146. detail the relationship of these parameters. In summary -
  147.  
  148. Paclen is used for ax25/netrom connects
  149.  
  150. MTU is used for TCP/IP connects and is the maximum data (and header)
  151. size that will be sent on an interface.
  152.  
  153. MSS is a negotiated value between the server/client - it uses the lowest
  154. of the two and cannot be larger than MTU. This however does not mean that
  155. intermediate hops could have lower allowed thruput - this is what the
  156. "dicovery" techniques that Phil and other have been talking about is
  157. suppose to adjust for.
  158.  
  159. The window is the maximum outstanding data - I.E. data in the pipeline.
  160.  
  161.  
  162. Typical values used here are based on our 2400 baud 2 meter circuit.
  163.  
  164. MTU - 512
  165. MSS - 472
  166. window - 944
  167. paclen 256
  168.  
  169. Paclen is limited by the maximum that MOST netrom sites can handle.
  170. For NOS to NOS connections this could be made larger - X1x sites
  171. allow a larger paclen - but be careful here as you may run into trouble.
  172.  
  173. This is a good example of why mss/window and paclen per interface values
  174. make sense. Strictly speaking though you should be able to set your MTU
  175. per interface and set the MSS/window much larger and let it adjust. I.E.
  176. set you mss to the header size less than the maximum MTU on your system.
  177.  
  178. If using ethernet - you might set
  179.  
  180. MTU - 1500 on the ethernet port
  181. MTU - 512 on a 2400 baud local port
  182. MTU - 256 on a 1200 baud local port
  183.  
  184. etc.
  185.  
  186. and set MSS= 1470, window = 2940
  187.  
  188. In practice this is suppose to work - I am not sure if there may not
  189. be some problems in NOS.
  190.  
  191. Phil may want to comment on this as I believe he wrote the description
  192. of it in the manual (way back) and he certainly knows the inter-workings
  193. of it in NOS.
  194.  
  195. Doug
  196.  
  197. ------------------------------
  198.  
  199. Date: Fri, 28 Jan 1994 11:38:30 -0800
  200. From: Phil Karn <karn@qualcomm.com>
  201. Subject: TCP MSS and TCP WIN settings
  202. To: goldstein@carafe.tay2.dec.com
  203.  
  204. >Raj describes that as a classical fallacy, albeit one with much
  205. >political clout.  You can't solve congestion with bandwidth, just
  206. >move it.  Now the backbone is fat but congestion occurs at the low-
  207. >bandwidth egress points ("on-ramps").  ATM nets will really see this.
  208.  
  209. Agreed. Another effect of higher bandwidth is to remove the "usual"
  210. indication of congestion - increased delay. Since most of the packet
  211. switches haven't scaled their queue sizes proportionately to their
  212. link speeds, there's relatively little variation in queueing delay
  213. nowadays. Almost all of it is now speed-of-light delay, at least on
  214. the NSFNet backbone. You see little change as load increases until
  215. packets suddenly start dropping. This argues even more strongly for
  216. the DECbit scheme or something like it, since there's less that a TCP
  217. can use to infer that congestion is occurring.
  218.  
  219. >It's simpler than that.  The congestion window is in the receiver,
  220. >not the sender.  All you need to do is lower the advertised window
  221. >size, not echo back the bit.  That's an advantage of TCP over, say,
  222.  
  223. Yes, of course. Why didn't I think of that?
  224.  
  225. >That spare bit just sort of begs to be used for this, doesn't it? 
  226. >I think somebody once suggested it at IETF but got nowhere, but then
  227. >I only know that as hearsay and I don't even remember from whom.
  228.  
  229. It was probably me. I tried to talk this up at the IETF some years
  230. ago, but didn't get a lot of interest for some reason. Maybe this is
  231. something we could implement first in amateur radio, get a lot of
  232. experience with it, and then go to the IETF. You tend to get taken
  233. more seriously if you have more than just an idea, but an actual
  234. demonstration that your ideas work and work well.
  235.  
  236. Phil
  237.  
  238. ------------------------------
  239.  
  240. Date: Fri, 28 Jan 1994 06:54:25 -0800 (PST)
  241. From: resmana - petra christian university <resmana@iclnet93.iclnet.org>
  242. To: tcp-group@ucsd.edu
  243.  
  244. SUBSCRIBE mailing list Resmana
  245.  
  246. ------------------------------
  247.  
  248. Date: 28 Jan 94 12:56:13 GMT
  249. From: uucp@attmail.com
  250. To: tcp-group@UCSD.EDU
  251.  
  252. >From UCSD.EDU!owner-tcp-digest Fri Jan 28 04:30:02 PST 1994 remote from internet
  253. Received: by gw1.att.com; Fri Jan 28 07:55:31 EST 1994
  254. Received: from localhost by ucsd.edu; id EAA17272
  255.  sendmail 8.6.4/UCSD-2.2-sun
  256.  Fri, 28 Jan 1994 04:30:06 -0800 for tcp-digest-list
  257. Received: from localhost by ucsd.edu; id EAA17266
  258.  sendmail 8.6.4/UCSD-2.2-sun
  259.  Fri, 28 Jan 1994 04:30:04 -0800 for tcp-group-ddist
  260. Message-Id: <199401281230.EAA17266@ucsd.edu>
  261. Date: Fri, 28 Jan 94 04:30:02 PST
  262. From: internet!UCSD.EDU!tcp-group (Advanced Amateur Radio Networking Group)
  263. Errors-To: TCP-Group-Errors@UCSD.EDU
  264. Reply-To: internet!UCSD.EDU!TCP-Group
  265. Precedence: Bulk
  266. Subject: TCP-Group Digest V94 #25
  267. To: internet!UCSD.EDU!tcp-group-digest
  268.  
  269.  
  270. TCP-Group Digest            Fri, 28 Jan 94       Volume 94 : Issue   25
  271.  
  272. Today's Topics:
  273.                            GPIB and packet
  274.                              jnos gateway
  275.                         MTU, TCP MSS, TCP WIN
  276.            New NET/Mac (hamradio TCP/IP) for the Macintosh
  277.                      TPC MSS and TCP WIN per port
  278.  
  279. Send Replies or notes for publication to: <TCP-Group@UCSD.Edu>.
  280. Subscription requests to <TCP-Group-REQUEST@UCSD.Edu>.
  281. Problems you can't solve otherwise to brian@ucsd.edu.
  282.  
  283. Archives of past issues of the TCP-Group Digest are available
  284. (by FTP only) from UCSD.Edu in directory "mailarchives".
  285.  
  286. We trust that readers are intelligent enough to realize that all text
  287. herein consists of personal comments and does not represent the official
  288. policies or positions of any party.  Your mileage may vary.  So there.
  289. ----------------------------------------------------------------------
  290.  
  291. Date: Thu, 27 Jan 94 16:33:29 CST
  292. From: garnier@sol.med.ge.com (Dave Garnier  x7-4286)
  293. Subject: GPIB and packet
  294. To: tcp-group@ucsd.edu
  295.  
  296. *>FYI - 
  297. *>
  298. *>The Circuit Cellar BBS has a parallel to GPIB adapter info and SW
  299. *>
  300. *>GPIBLPT.ZIP
  301.  
  302. *I tried to look for it with archie but could not find any references. 
  303. *Could you put it somewhere where I could ftp this file from.
  304.  
  305.  
  306. Could some kind soul post the fone number to this group?
  307.  
  308. Thanks much!
  309.  
  310.  
  311.  
  312. dave garnier
  313. wb9own
  314. ge medical systems, milwaukee
  315.  
  316. garnier@sol.med.ge.com
  317.  
  318. ------------------------------
  319.  
  320. Date: Thu, 27 Jan 1994 08:22:14 -0500
  321. From: Gary Skuse <grsk@troi.cc.rochester.edu>
  322. Subject: jnos gateway
  323. To: TCP-Group@UCSD.Edu
  324.  
  325. I am running jnos on a dos box which is connected to a landline by a serial
  326. port and to our University's extended LAN via an ethernet connection.  I
  327. would like to set up a gateway between the two so that I can call in by
  328. telephone and get out over the Internet.  I can figure out how to telnet
  329. but I can't ftp.  Has anyone done this?  I would appreciate any suggestions
  330. anyone has to offer.  Eventually I would like to do something similar at home
  331. so that I can access my ethernet network at home via the telephone from 
  332. work.
  333.  
  334. tnx and 73, ka1njl
  335.  
  336. ------------------------------
  337.  
  338. Date: Thu, 27 Jan 1994 10:31:25 -0800 (PST)
  339. From: uswnvg!tconboy@uunet.UU.NET (Terry A. Conboy)
  340. Subject: MTU, TCP MSS, TCP WIN
  341. To: uunet!ucsd.edu!tcp-group@uunet.UU.NET
  342.  
  343. It seems that there is a minor confusion about these parameters.  My
  344. (probably meager) understanding is that your MTU determines the biggest
  345. datagram that you send (allowing for 40 bytes of TCP/IP overhead) and
  346. that MSS and WIN control what is sent TO you.  In other words, if you
  347. are sending mail or files to another host, your MSS and WIN have no
  348. effect on what you send out to them.
  349.  
  350. I have a PC with a 1200 bps KISS TNC and a 2400 bps SLIP link.  I set
  351. the MTU on the TNC to 296 since the radio path is sometimes
  352. marginal to some stations I communicate with.  I set the MTU on the SLIP
  353. to 1064 to allow big datagrams to be sent to my computer at work
  354. over a 2400 bps dialup.  I set TCP MSS to 1024 and TCP WIN to 2048 to
  355. allow up to 2 datagrams to be outstanding without an ACK.
  356.  
  357. This works well in practice, since the congestion window (Cwind)
  358. typically gets adjusted down to the MTU-40 of the station at the other
  359. end of the radio link very quickly.  So for me, having MSS or WIN per
  360. port isn't very important.  However, it does require that the station at
  361. the other end of a radio link be intelligent in setting his MTU on the
  362. radio port.
  363.  
  364. I've gleaned this from reading the docs, watching lots of traces, and
  365. looking at the 'socket nnn' displays.  If there's a flaw in my
  366. reasoning, let me know.
  367.  
  368. 73, Terry
  369. -- 
  370. Terry Conboy     email: tconboy@uswnvg.com
  371. U S WEST NewVector Group   packet: n6ry@n7ipb.wa.usa
  372. 3350 - 161st Ave SE,  MS 571   office: (206) 450-8388
  373. Bellevue, WA 98008    fax:    (206) 450-8399
  374.  
  375. ------------------------------
  376.  
  377. Date: Thu, 27 Jan 1994 10:13:03 +0100
  378. From: adam@igg.tno.nl (Adam van Gaalen PA2AGA)
  379. Subject: New NET/Mac (hamradio TCP/IP) for the Macintosh
  380. To: ham-digital@ucsd.edu, tcp-group@ucsd.edu
  381.  
  382.  
  383.                                             The Netherlands, January 25, 1994.
  384. Hello dear reader,
  385.  
  386. Today I distributed the file NET_Mac2.3.35.sea.hqx...
  387.  
  388. In this version of NET/Mac I implemented the following:
  389.  
  390. - New <dayofweek> parameter for 'perform' command
  391. - New: 'reboot_on_bad_date' }  These new commands were implemen-
  392. - New: 'sourcewhendone'     }  ted to make it easier to maintain
  393. - New: 'resetsmtpto'        }  an unattended slip-telephone-link
  394. - Improved the generation of dynamic aliases
  395. - Some more 'enhancements' for q-and-d AppleTalk-fix
  396. - Some more 'enhancements' for q-and-d fix
  397.  
  398. This version obsoletes all versions of info-mac/comm/radio-netmac in the
  399. Sumex-Aim archives.
  400.  
  401. The new NET/Mac has been uploaded to ucsd.edu, to the directory
  402. /hamradio/packet/tcpip/incoming. If it's not there (anymore),
  403. then look at /hamradio/packet/tcpip/mac.
  404.  
  405. Kind regards,
  406.  
  407. Adam PA2AGA  (e-mail: adam@igg.tno.nl  )
  408.              (    or: pa2aga@igg.tno.nl  for letters only, NO BIG files here)
  409.  
  410. ------------------------------
  411.  
  412. Date: Thu, 27 Jan 94 07:04:23 CST
  413. From: Jack Snodgrass                    <kf5mg@kf5mg.ampr.org>
  414. Subject: TPC MSS and TCP WIN per port
  415. To: tcp-group mailling list             <tcp-group@ucsd.edu>
  416.  
  417.    Someone posted a message or sent me a note saying that they had fixed
  418. JNOS to allow a MSS and WINDOW value to be asinged to each port. I forgot
  419. who it was, but they said that they'd post the changes this week. I'm 
  420. anxios to see the code. I've tried setting the MTU on the port to less than
  421. the TCP MSS and I'm not happy with the results. Stuff seems to go smoother
  422. when I just reduce the MSS for the entire system rather than reducing the
  423. MTU for a single port. I see packets being broken up into mtu size pieces 
  424. but NOS doesn't seem to re-assemble them and acknowledge them all the time.
  425. I'm not familiar enough with the process to figure out what's wrong, but
  426. I did see the same group of MTU sized packets be sent several times and 
  427. never ack'd by the receiving system. Anyway... I'd like to mod the code
  428. to use a MSS and WINDOW based on the port. At least in my enviornment, 
  429. stuff does not change from port to port so that should not cause a problem.
  430. Thanks.
  431.  
  432. 73's  de  Jack  -  kf5mg
  433. Internet        -  kf5mg@kf5mg.ampr.org            -  44.28.0.14
  434. AX25net         -  kf5mg@kf5mg.#dfw.tx.usa.noam    -  home (817) 488-4386
  435. Dialup          -  kf5mg@tcet.unt.edu              -  work (looking  for)
  436.  
  437. ------------------------------
  438.  
  439. End of TCP-Group Digest V94 #25
  440. ******************************
  441.  
  442. ------------------------------
  443.  
  444. End of TCP-Group Digest V94 #26
  445. ******************************
  446. ******************************
  447.